Software distribution adds significantly to the total cost of ownership associated with a distributed system due to the need to: (i) identify computing devices or machines (“targets”) that need to be updated with a specific software package from an enterprise perspective; (ii) make sure that targets have the right services and components present (e.g., operating system, services and applications), and that these services have the right versions; and (iii) make sure that targets have the prerequisite set of resources (e.g., CPU (central processing unit) type and clock speed, memory, disk storage, paging space, etc.), in order to be able to receive and run the new software item.
Most existing software distribution mechanisms store information about target machine configuration and requirements in a central database and require the involvement of human operators, thus making the procedure inefficient, unscalable, costly, and error-prone. They often rely on the target machine user to select the software packages (“pull-based approach”) that should be distributed and installed, see, e.g., U.S. Pat. No. 5,953,533 issued to Fink et al. on Sep. 14, 1999 and entitled “Computer Software Distribution, Installation and Maintenance Method and Apparatus;” and U.S. Pat. No. 5,999,740 issued to Rowley on Dec. 7, 1999 and entitled “Updating Mechanism for Software.”
Existing approaches for “push-based” software distribution usually require the manual selection of potential distribution targets by a software distribution administrator and, therefore, put the burden of decision making on a human operator, leading basically to the same problems as the pull-based approach described above.
FIG. 1 illustrates the procedure implemented in a typical conventional software distribution system. In step 1, an administrator 10 prepares a new software item to be distributed to a set of desktop machines. This is preferably done in a machine 14 dedicated to building software packages which contains the requisite operating system components for doing so. In step 2, a configuration file or database 12 is consulted to determine which target machines should receive the new software. This configuration file is typically updated and maintained by a group of administrators, requiring considerable human interaction and thus is often out of sync with the real states of the target machines. In step 3, the new software package is stored in a package repository 16. In step 4, there is a request for distribution of the software package from the administrator 10 to a distribution computer system or server 18. In step 5, the package is downloaded to the distribution server 18. Lastly, in step 6, the package is distributed by the distribution server 18 to the distribution target computer systems 20-1, 20-2, . . . , 20-N.